home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Magnum One
/
Magnum One (Mid-American Digital) (Disc Manufacturing).iso
/
d21
/
qw12.exe
/
QWHITE12.EXE
/
EXCEPT13.TEC
< prev
next >
Wrap
Text File
|
1990-10-08
|
7KB
|
124 lines
ID:13 Exception #13 and QEMM
Quarterdeck Technical Note
by Bob Perry and Dan Sallitt
Q: What is "Exception #13"?
Q: What can be done to prevent "Exception #13"s?
Exceptions are unusual or invalid conditions associated with
the execution of a particular instruction by the 80386 processor
(or higher processors). The 80386 recognizes several different classes
of exceptions, and assigns a different vector number to each class. The
DESQview-386 memory manager, QEMM-386, has been designed to capture
these 80386 exception vectors and display them directly to the user.
Exception #13 is the "General Protection Fault" error. Any
privileged instruction or any instruction that references memory can
trigger an Exception #13.
In the first case, privileged instructions, the Exception #13
could indicate that a program has violated the protected mode of the
80386 by executing a privileged instruction or I/O reference. Thus,
when the prompt "Terminate, Reboot or Continue?" is issued, the
"Continue" option puts the system back into real mode, and the program
should continue to execute. (After choosing the "Continue" option, one
should not necessarily assume that the system is stable. A reboot at
the earliest convenient time is probably wise.)
It is the second case, instructions that reference memory, that is
far more common to DESQview 386 (and QEMM-386) users. Here the
exception may indicate that an application has a bug, or that adverse
circumstances have sent it out of control. It has overwritten its
memory partition, and may in fact be running wild, writing code all over
the place. This situation can occur with some programs that were
written for use on the 8088 processor and may not be usable in the
80386's virtual 8086 mode. A few other programs may not be compatible
with QEMM-386. In some cases the problem occurs even without QEMM
present (in which case it manifests itself as a crash instead of an an
error message). What this usually adds up to is that when "Terminate,
Reboot or Continue" is displayed, the user can usually only "Terminate."
For those users who are more technically oriented, this over-
writing of the memory partition generally means that a word or a
double word value of code has been written to the last byte of a
segment. The problem or "bug" in the application program or in the
system shows up as an attempt to wrap the value to the next segment of
memory.
What can the user do to prevent Exception #13's? Because a great
many problems can result in Exception #13's, it is sometimes necessary
to resort to general troubleshooting techniques. The DESQview 386 user
should start with two simple steps: first, run Change a Program and try
to allocate more memory to the application. Second, the user can try to
increase the protection level of the afflicted window to 3, which will
not remove the source of the Exception #13, but may pass more
descriptive error messages through to the user.
When Exception #13's are obtained outside of DESQview they are
either caused by applications written for the 80386 protected mode or
they are not. If the faulting application is written for the protected
mode of the 80386, it is likely that this program has no VCPI (Virtual
Control Program Interface) support. Since QEMM-386 is a protected mode
program, such faulting applications cannot be run under QEMM without
VCPI. The user has no choice but to reboot without QEMM, and contact
the developer of the faulting application to request VCPI support.
If the faulting application was not written for the protected mode
of the 80386, a good possibility is that the QEMM user has installed
QEMM with the RAM parameter (which is necessary to LOADHI drivers and
TSR's). In this case the faulting program may be running in an area of
high RAM that contains a memory conflict. To correct this problem, the
user may opt to RAM only specific areas of memory, as described on page
6 of the QEMM-386 manual, rather than to RAM all mappable areas. Of
course, an area of conflict that is not RAMmed is still an area of
conflict, and may cause problems if another application tries to map
expanded memory into that region. A better solution to such memory
conflicts might be to use the EXCLUDE parameter (described on page 5 of
the QEMM manual) on the area in conflict.
When in doubt about which areas to exclude, the user may wish to
pay special attention to areas that are marked "Rammable" on the
QEMM.COM Type screen, or to High RAM areas in the F000-FFFF area.
"Rammable" areas are usually adjacent to ROM areas, and the possiblilty
exists that the ROM is slightly bigger than QEMM could detect and is
spilling over into the "Rammable" area. High RAM areas in the F000-FFFF
region are mapped over pieces of the system ROM that either QEMM or the
user have judged not to be in use. Obviously, this judgment should be
questioned when Exception #13 messages occur. The F000-FFFF area should
be scrutinized especially carefully when floppy disk access generates
the exception error.
The QEMM.COM Accessed screen (also available as the Manifest QEMM-
386\Accessed screen) can give the user valuable hints about what areas
of memory are in use. To use the Accessed screen, replace the RAM
parameter on the QEMM line in the CONFIG.SYS file with the ON parameter
and reboot the machine. Any area that the Accessed screen then shows as
having been touched, but that the Type screen shows as Mappable or
Rammable, is a good candidate for exclusion. If the Exception #13 error
only occurs with the RAM parameter present, you can now safely perform
the action that usually generates the error, then consult the Accessed
screen to see what areas of memory have been newly touched.
Some pieces of hardware can come into conflict with QEMM or DESQview and
generate Exception #13 errors. The most frequent offenders are bus-
mastering devices (hard disk controllers, network cards, CD-ROM
controllers, etc.) and autoswitching video cards. Bus-mastering hard
disk controllers often cause Exception #13 errors upon any use of the
LOADHI programs, for instance. For approaches to this problem, see the
Quarterdeck Technical Note titled "Bus-Mastering Devices and QEMM-386."
Not all autoswitching video cards come into conflict with QEMM or other
pieces of software. When a conflict occurs, however, it does not always
take the form of a video problem, and sometimes results in the Exception
#13 message. Disabling autoswitching is the only solution to such a
problem.
General troubleshooting methods, like temporarily removing all TSR's,
device drivers and questionable QEMM parameters, often provide valuable
information about the exception error. It sometimes happens that a
circumstance that generates an Exception #13 with QEMM present simply
causes the machine to crash without any message when QEMM is removed.
In such a case, QEMM is simply the bearer of bad news.
Copyright (C) 1990 by Quarterdeck Office Systems
* * * E N D O F F I L E * * *